Halogen Component

Halogenのversionによってやや書き方が異なる

Qiitaで見かける昔の解説は少し異なっていたりする

いくつかのパーツからなる

この辺の一連の部品を総称してComponentと呼ぶ

Component

以下のモノ達をを結びつける関数

State型

initialState

Action型

handleAction

render関数

考え方

どこから作っていくのか？

型駆動でやりたいので、普通はcomponentの型から考えるのかな

逆にCOmponentは一番最後という説もある

H.Componentをちゃんと理解していないので今は厳しいが理想的には

State, Actionの型はイメージしやすい

静的か動的か、propsの有無で色々変わる

状態を持つ場合

componentとして作るが、親からの変更を受け取るかどうか(?)で型が異なる

単純なものの場合、slotは必要ない

入れ子になったときに親、子に何を書くか

code:child.purs(hs)

type Slot p = ∀ query. H.Slot query Void p

_home :: Proxy "home"

_home = Proxy

component :: ∀ q i o m. H.Component q i o m

component =

H.mkComponent

{ initialState: identity

, render

, eval: H.mkEval H.defaultEval

}

where

render :: ∀ state action m. state -> H.ComponentHTML action () m

親

code:parent.purs(hs)

type ChildSlots =

( home :: Home.Slot Unit

-- , feed :: Register.Slot Unit

)

render :: ∀ m. State -> H.ComponentHTML Action ChildSlots m

render st = navbar $ case st.route of

Just route -> case route of

Home -> HH.slot Home._home unit Home.component unit absurd

Halogen Componentに関するフローチャート

状態を持たない静的componentは、そもそもcomponentとして作る必要がない

親から受け取ったinputを表示するcomponent

たぶんこれ自体を使うことはほとんど無い

自分で状態を持たないし、親からの連続的な変化を反映しない(reciverがないので)

親からの連続的案変更を反映するcomponent

子の方のmkComponent内のevalにreciveを設定する

halogen界で一般的とされるアーキテクチャはあるのか？

たとえばstore的なやつは分割はせずひとかたまりにする、とか

非同期通信

ライフサイクル

code:purs(hs)

data Component

(query :: Type -> Type)

(input :: Type)

(output :: Type)

(m :: Type -> Type)